Skip to content

Comments

Fix atrocity arg parsing#91

Draft
supervoidcoder wants to merge 7 commits intomainfrom
fix-atrocity-arg-parsing
Draft

Fix atrocity arg parsing#91
supervoidcoder wants to merge 7 commits intomainfrom
fix-atrocity-arg-parsing

Conversation

@supervoidcoder
Copy link
Owner

No description provided.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 16, 2026

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix-atrocity-arg-parsing

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@supervoidcoder
Copy link
Owner Author

@coderabbitai hmm I have so much planned for this... What do you think of much smarter arg parsing I think this will be pretty fun

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 16, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Get the diff for this PR to see what's being changed
gh pr diff 91

# Also check the current state of main.cpp to understand the context
echo "=== Current main.cpp content ==="
cat main.cpp | head -500

Length of output: 22018


@supervoidcoder Oh this is exciting! I love where you're going with this. 🎉

The current changes moving to std::vector<std::string> are already a solid foundation - it's way safer than raw pointer arithmetic and makes the code less error-prone. But yeah, there's SO much room to make this even smarter!

Here are some ideas for taking this to the next level:

1. Structured Argument Parser Class
You could create a dedicated class that handles all the parsing logic:

  • Store flags and their values in a map/unordered_map
  • Support both short (-p) and long (--pid) format
  • Handle flag aliases automatically
  • Make it easy to check if (args.has("pid")) instead of manual string comparisons

2. Subcommands Support
Since you have process inspection, you could potentially add subcommands like:

  • win-witr inspect <name/pid>
  • win-witr list (show all processes)
  • win-witr monitor <name/pid> (continuous monitoring)

3. Value Validation at Parse Time
Instead of parsing --pid and then converting/validating later, validate during the parse phase:

  • Type-safe getters like args.getInt("pid") that throw meaningful errors
  • Enum-based flags for compile-time safety
  • Required vs optional argument tracking

4. Better Error Messages
With smarter parsing you can provide helpful suggestions:

  • "Did you mean --pid instead of --pd?"
  • "Flag --pid requires a value"
  • Auto-generate usage info from the parser configuration

5. Chained Operations

win-witr --pid 1234 --details --ports --cmdline

Where each flag adds a section to the output.

The comment about "never increment the actual variable" suggests you've hit some of the pain points of manual parsing - a proper parser would handle that state management for you automatically!

What direction were you thinking? I'm curious what you have planned! 🚀


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

@supervoidcoder
Copy link
Owner Author

@coderabbitai i'm thinking of adding a --verbose flag, but what would the shorthand be? -v is already for --version

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 16, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check current flag usage in main.cpp to see what's already taken
echo "=== Current flag usage in main.cpp ==="
rg -n "argv\[i\] == \"--?[a-z]" main.cpp || rg -n "\"--?[a-z]" main.cpp | head -50

Length of output: 221


@supervoidcoder Good question! This is a classic CLI flag collision. Here are your best options:

1. -V (capital V)

  • Most common solution when lowercase is taken
  • Used by: gcc -V, pip -V (shows version with capital)
  • Intuitive since it's visually related to verbose
  • Example: win-witr -V --pid 1234

2. No shorthand at all

  • Just use --verbose
  • Keeps things clean and unambiguous
  • Used by many modern tools when conflicts arise
  • You already do this with --pid

3. -d (for debug/detailed)

  • Common alternative meaning
  • Used by: ssh -d, curl -d (though curl's is for data)
  • Fits well since verbose output is typically for debugging
  • Example: win-witr -d --pid 1234

4. -vb or -vbs

  • Unique and no collision
  • A bit unconventional but memorable
  • Less common in the wild

My recommendation: Go with -V (capital V). It's the most conventional solution in the Unix/Linux world when lowercase -v is already taken for version. Users will recognize the pattern immediately, and it keeps the mnemonic connection to "verbose."

Plus, if you ever want verbose levels later, you could do -VV or -VVV for increasing verbosity! 🚀

What do you think?


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

@supervoidcoder
Copy link
Owner Author

@coderabbitai also i just remembered
since this is a windows only tool anyways, we should add windows style flags too
yknow, with the /

like shutdown /h instead of shutdown -h (which works too but yknow)

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 16, 2026

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Oh YES! That's such a nice touch for a Windows-native tool! 🎯

You're absolutely right - Windows has its own CLI heritage with the / style flags, and it would make win-witr feel more at home on Windows. Plus, many Windows power users instinctively reach for / first.

The best part: You can support both styles simultaneously! Many modern Windows tools do this:

  • shutdown /h
  • shutdown -h ✅ (also works)
  • ipconfig /all vs ipconfig -all (both work in many tools)

Implementation approach:

When parsing args, just normalize the prefix:

std::string normalizeFlag(const std::string& arg) {
    // Convert /flag to --flag or /-f to -f
    if (arg[0] == '/') {
        if (arg.length() == 2) {
            return "-" + arg.substr(1);  // /v -> -v
        } else {
            return "--" + arg.substr(1); // /verbose -> --verbose
        }
    }
    return arg;
}

Then parse as usual. This way you get:

  • win-witr /pid 1234
  • win-witr --pid 1234
  • win-witr /v (for version) ✅
  • win-witr /V (for verbose) ✅
  • win-witr /verbose

Examples of how it would look:

win-witr /p 1234
win-witr /pid 1234 /V
win-witr /name explorer.exe /verbose

Gives it that authentic Windows CLI vibe! And users coming from Unix/Linux backgrounds will still feel at home with - and --. Win-win! 🚀

Do you want to support both styles, or go full Windows and use / exclusively?


✏️ Learnings added
Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/pull/91

Timestamp: 2026-02-16T15:24:08.444Z
Learning: The user wants to add Windows-style flag syntax using `/` prefix (e.g., `/pid`, `/v`, `/verbose`) to win-witr since it's a Windows-only tool, following Windows CLI conventions like `shutdown /h`. Supporting both Unix-style (`-`, `--`) and Windows-style (`/`) flags simultaneously is preferred for user flexibility.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

@supervoidcoder
Copy link
Owner Author

@coderabbitai uh oh i did it again

main.cpp
main.cpp(1748): error C2059: syntax error: ')'
main.cpp(1748): error C2143: syntax error: missing ')' before '{'
main.cpp(2074): error C2061: syntax error: identifier 'i'
main.cpp(2074): error C2143: syntax error: missing ';' before '{'
main.cpp(2075): error C2059: syntax error: '['
main.cpp(2075): error C2143: syntax error: missing ';' before '{'
main.cpp(2076): error C2065: 'i': undeclared identifier
main.cpp(2076): error C2181: illegal else without matching if
main.cpp(2077): error C2065: 'i': undeclared identifier
main.cpp(2078): error C2065: 'i': undeclared identifier
main.cpp(2081): error C2065: 'i': undeclared identifier
main.cpp(2083): error C2065: 'i': undeclared identifier
main.cpp(2197): error C2660: 'PIDinspect': function does not take 3 arguments
main.cpp(1748): note: see declaration of 'PIDinspect'
main.cpp(2197): note: while trying to match the argument list '(std::vector<DWORD,std::allocator<DWORD>>, std::vector<std::string,std::allocator<std::string>>, HANDLE)'
main.cpp(2215): error C2065: 'arg': undeclared identifier
main.cpp(2221): error C2660: 'PIDinspect': function does not take 3 arguments
main.cpp(1748): note: see declaration of 'PIDinspect'
main.cpp(2221): note: while trying to match the argument list '(std::vector<DWORD,std::allocator<DWORD>>, std::vector<std::string,std::allocator<std::string>>, HANDLE)'
Error: Process completed with exit code 1.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check out the PR branch and read the main.cpp file at the problematic lines
cat main.cpp | sed -n '1740,1760p'
echo "=== Line 2070-2085 ==="
cat main.cpp | sed -n '2070,2085p'
echo "=== Line 2195-2200 ==="
cat main.cpp | sed -n '2195,2200p'
echo "=== Line 2213-2223 ==="
cat main.cpp | sed -n '2213,2223p'

Length of output: 1999


@supervoidcoder Oh no! 😅 Classic language-mixing moment - you've got Python syntax in your C++ code!

Here are the issues:

1. Line 1748 - Trailing comma in function signature:

void PIDinspect(..., int related,   ) {  // ❌ trailing comma!

Should be:

void PIDinspect(..., int related) {  // ✅ no trailing comma

2. Line 2074-2075 - Python-style for loop:

for i in args.size() {           // ❌ Python syntax!
    if (args.[i].at(0) == "/") { // ❌ stray period!

Should be:

for (size_t i = 0; i < args.size(); i++) {  // ✅ C++ syntax
    if (args[i].at(0) == "/") {              // ✅ no period

3. Lines 2197 & 2221 - Wrong number of arguments:

PIDinspect(pids, trash, hshot);  // ❌ only 3 args, needs 5!

Your function signature expects: (pids, names, hshot, statuses, related)

You need to either:

  • Pass the missing arguments: PIDinspect(pids, trash, hshot, someStatusVector, 0);
  • Or change the function signature to make those params optional/have defaults

4. Line 2215 - Undeclared variable:

std::string procName = arg;  // ❌ where's 'arg' from?

Here's the corrected normalizeArgs function:

std::vector<std::string> normalizeArgs(std::vector<std::string>& args) {
    for (size_t i = 0; i < args.size(); i++) {
        if (args[i].at(0) == "/") {
            args[i].erase(0, 1);
        } else if (args[i].at(0) == "-") {
            if (args[i].at(1) == "-") {
                args[i].erase(0, 2);
            } else {
                args[i].erase(0, 1);
            }
        }
    }
    return args;
}

Fix that trailing comma first - it's cascading all the other errors! 🐛

  /\_/\
 ( o.o )
  > ^ <
"oopsie!"

🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-03T03:55:12.808Z
Learning: In supervoidcoder/win-witr PR `#60`, cross-bitness support is working: an x86 build can read CommandLine from 64-bit target processes on x64 Windows (via the WoW64 path). CI logs on Feb 3, 2026 show successful PEB CommandLine extraction for winlogon.exe (GUID arg), lsass.exe, and svchost.exe (-k DcomLaunch -p); protected/pseudo processes still fail as expected.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-11T22:24:16.464Z
Learning: In supervoidcoder/win-witr PR `#84`, the user achieved a ~27% performance improvement (from 19.41ms to 14.15ms average per lookup) through several key optimizations: (1) using a single CreateToolhelp32Snapshot passed through all functions instead of creating multiple snapshots, (2) implementing a pidMap hash map for O(1) process lookups instead of linear search, (3) removing the redundant exeTimes vector, (4) using emplace instead of copy assignment for map insertions, and (5) caching terminal VT capability to avoid repeated checks. This refactoring took ~3 hours and involved 224 additions and 193 deletions in main.cpp.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:14:03.795Z
Learning: In supervoidcoder/win-witr, release builds are compiled with documented flags: `cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /DVERSION_NUMBER=$verTag /Fe:$outName`. The version number is compiled into the binary via the VERSION_NUMBER macro (from git tag), which means each release has a unique binary hash even for minor patches. This is necessary for the --version command to work correctly. Builds produce architecture-specific executables: win-witr-x64.exe, win-witr-x86.exe, and win-witr-arm64.exe.
</add_learning>

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-16T15:24:08.462Z
Learning: The user wants to add Windows-style flag syntax using `/` prefix (e.g., `/pid`, `/v`, `/verbose`) to win-witr since it's a Windows-only tool, following Windows CLI conventions like `shutdown /h`. Supporting both Unix-style (`-`, `--`) and Windows-style (`/`) flags simultaneously is preferred for user flexibility.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-10T03:14:44.242Z
Learning: In supervoidcoder/win-witr PR `#80`, the user implemented a "Related Processes" feature to handle duplicate process names. When multiple processes match a name, the tool shows the first found process as the main output, then lists all other matches below in a "Related Processes:" section showing both process name and PID. This is non-interactive and uses colored output (magenta header, cyan names, gray PIDs).

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-12T14:03:25.649Z
Learning: In supervoidcoder/win-witr issue `#77`, the user decided to add process handles enumeration as an opt-in flag (likely `--detailed` or `--full`) instead of making it default behavior. Default mode shows handle count only to preserve the 15.24ms average performance, while the flag enables full handle enumeration with type/name details at the cost of performance. This architectural decision keeps the benchmark-winning speed for normal use while offering completeness for users who need detailed handle inspection.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

@supervoidcoder
Copy link
Owner Author

supervoidcoder commented Feb 23, 2026

@coderabbitai frick i'm so stupid my python kicked in 🤣🤣🤣🤣🤣🤣🤣🤣🤣

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Hahaha happens to the best of us! 😄 Context switching between languages is rough - your brain is in Python mode and suddenly for i in just flows out naturally!

At least the compiler caught it immediately instead of letting it slide into some weird runtime bug. Now you know the fix - just gotta channel your C++ energy! 🚀

Good luck with the rest of the arg parsing refactor! 💪


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

@supervoidcoder
Copy link
Owner Author

@coderabbitai still broken but now i have different problems am i just that bad

main.cpp(1752): error C2059: syntax error: ')'
main.cpp(1752): error C2143: syntax error: missing ')' before '{'
main.cpp(2079): error C2446: '==': no conversion from 'const char [2]' to 'int'
main.cpp(2079): note: There is no context in which this conversion is possible
main.cpp(2080): error C2440: '=': cannot convert from 'const char [2]' to 'char'
main.cpp(2080): note: There is no context in which this conversion is possible
main.cpp(2081): error C2446: '==': no conversion from 'const char [2]' to 'int'
main.cpp(2081): note: There is no context in which this conversion is possible
main.cpp(2082): error C2446: '==': no conversion from 'const char [2]' to 'int'
main.cpp(2082): note: There is no context in which this conversion is possible

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the problematic lines from main.cpp
echo "=== Line 1750-1755 (function signature error) ==="
cat main.cpp | sed -n '1750,1755p'
echo ""
echo "=== Lines 2075-2085 (string/char comparison errors) ==="
cat main.cpp | sed -n '2075,2085p'

Length of output: 1018


@supervoidcoder No way, you're not bad! This is just classic Python-to-C++ brain confusion! 😄

You've got two issues:

1. Line 1752 - Still that trailing comma:

void PIDinspect(..., int related,   ) {  // ❌ trailing comma!

Remove the comma after related:

void PIDinspect(..., int related) {  //

2. Lines 2079-2082 - String literals vs Character literals:

In C++, there's a BIG difference:

  • Single quotes '/' = character literal (type: char)
  • Double quotes "/" = string literal (type: const char[2])

When you do args[i].at(0), it returns a char, so you need to compare/assign with single quotes!

Your current code:

if (args[i].at(0) == "/") {        // ❌ comparing char with string
    args[i].at(0) = "-";            // ❌ assigning string to char
} else if (args[i].at(0) == "-") { // ❌ comparing char with string
    if (args[i].at(1) == "-") {    // ❌ comparing char with string

Fixed code:

if (args[i].at(0) == '/') {        // ✅ comparing char with char
    args[i][0] = '-';               // ✅ assigning char to char
} else if (args[i].at(0) == '-') { // ✅ comparing char with char
    if (args[i].at(1) == '-') {    // ✅ comparing char with char

Python doesn't care about single vs double quotes - they're interchangeable for strings! But C++ is strict about this. Your Python brain is just being helpful in the wrong language! 🐍➡️🤖

Fix those quotes and that comma and you should be golden! 🚀


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

@supervoidcoder
Copy link
Owner Author

@coderabbitai yay it works now!

but so far my code changes in this pr aren't that useful... it's just being able to say -help, --help or /help

@supervoidcoder
Copy link
Owner Author

supervoidcoder commented Feb 23, 2026

@coderabbitai surprisingly it doesn't seem to impact performance at all though, not even a millisceond! why

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Woohoo! 🎉 Glad you got it compiling!

And hey, don't sell yourself short - flag normalization is actually really useful infrastructure! It's the foundation that lets you do all the cool stuff you mentioned wanting to add. Think of it this way:

What you've built:

  • Users can now use -help, --help, or /help interchangeably
  • Windows users feel at home with / style flags
  • Unix/Linux users can use their familiar - and --
  • You've separated the "understanding input" logic from the "processing commands" logic

What this unlocks for you now:
You can build the smarter parsing on top without worrying about / vs - vs -- ever again! Here are natural next steps:

  1. Add more flags easily: Now adding /verbose, /pid, /name etc. is trivial
  2. Structured flag storage: Create a map or struct to hold parsed flags instead of manual if/else chains
  3. Flag validation: Check for unknown flags and give helpful errors
  4. Value parsing: Handle flags with values like /pid 1234 cleanly
  5. Help generation: Auto-generate usage info from your flag definitions

Since you mentioned wanting "much smarter arg parsing" - is the next step adding those other flags (/verbose, /V, etc.) or are you thinking of refactoring how flags are stored/processed? 🤔

This is solid progress! Each small piece compounds into something awesome. 🚀


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 23, 2026

Tip

For best results, initiate chat on the files or code changes.

@supervoidcoder Oh that's actually a great observation to make! Here's why you're seeing zero impact:

Argument parsing is basically free

Your normalizeArgs() function runs exactly once at startup before any process inspection happens. It's processing maybe 2-10 strings max (however many flags the user passes), and doing simple character comparisons like if (args[i].at(0) == '/').

The numbers:

  • Your normalization: ~100-500 nanoseconds (0.0001-0.0005 ms)
  • Your process inspection: ~15 milliseconds per lookup

That's a 30,000x difference! It's like worrying about the weight of a paperclip when you're carrying a backpack full of textbooks. 📚

Where the real time goes (from your PR #84 learnings):

  1. CreateToolhelp32Snapshot - scanning all processes
  2. NtQueryInformationProcess - reading PEB data
  3. OpenProcess - getting process handles
  4. ReadProcessMemory - cross-process reads for CommandLine
  5. Terminal VT capability checks

These are system calls that cross into kernel mode, wait for I/O, and do actual work. String manipulation in user-mode memory? Lightning fast by comparison! ⚡

So your flag normalization could be 10x more complex and you still wouldn't see it in your benchmarks. The only time argument parsing matters for performance is if you're a tool like ls or grep that gets called thousands of times per second in scripts!

tl;dr: You're good! Focus on making it clean and feature-rich - performance isn't a concern here. 🚀


✏️ Learnings added
Learnt from: supervoidcoder
URL: https://github.com/supervoidcoder/win-witr/pull/91

Timestamp: 2026-02-23T13:59:55.527Z
Learning: In supervoidcoder/win-witr, argument parsing (flag normalization for `/`, `-`, `--` prefixes) has no measurable performance impact because it runs once at startup on a tiny dataset (< 10 args), taking nanoseconds, while the actual process inspection operations (CreateToolhelp32Snapshot, NtQueryInformationProcess, ReadProcessMemory) take ~15ms and dominate the performance profile.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-16T15:24:08.462Z
Learning: The user wants to add Windows-style flag syntax using `/` prefix (e.g., `/pid`, `/v`, `/verbose`) to win-witr since it's a Windows-only tool, following Windows CLI conventions like `shutdown /h`. Supporting both Unix-style (`-`, `--`) and Windows-style (`/`) flags simultaneously is preferred for user flexibility.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:14:03.795Z
Learning: In supervoidcoder/win-witr, release builds are compiled with documented flags: `cl /O2 /Ot /GL /std:c++20 /EHsc main.cpp /DUNICODE /D_UNICODE /DVERSION_NUMBER=$verTag /Fe:$outName`. The version number is compiled into the binary via the VERSION_NUMBER macro (from git tag), which means each release has a unique binary hash even for minor patches. This is necessary for the --version command to work correctly. Builds produce architecture-specific executables: win-witr-x64.exe, win-witr-x86.exe, and win-witr-arm64.exe.
</add_learning>

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 48
File: README.md:38-38
Timestamp: 2026-01-21T01:52:33.870Z
Learning: For supervoidcoder's README files in the win-witr repository: The user prefers an intentionally informal, humorous tone with casual language. Grammar formality suggestions (like "anyways" vs "anyway") should be skipped as they don't align with the intentional style of the documentation.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 58
File: main.cpp:380-400
Timestamp: 2026-01-29T22:00:51.099Z
Learning: In the supervoidcoder/win-witr repository, the user intentionally uses meme/humorous spellings in code comments (e.g., "vroken" instead of "broken") as part of an informal coding style. These should not be flagged as typos.

Learnt from: supervoidcoder
Repo: supervoidcoder/win-witr PR: 0
File: :0-0
Timestamp: 2026-02-21T04:10:07.627Z
Learning: supervoidcoder is a high school student without budget for commercial solutions like EV code signing certificates ($200-500/year). Future suggestions should focus on free/open-source approaches for the win-witr project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant